home *** CD-ROM | disk | FTP | other *** search
/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / prgtools / programm.ing / pt_src3t.lzh / PT_SRC3T / PT_INFO.S next >
Encoding:
Text File  |  1994-01-02  |  7.6 KB  |  156 lines
  1. ;----------------------------------------------------------
  2. ;
  3. ;
  4. ;
  5. ;
  6. ;
  7. ;
  8. ;                PROtracker replay routine
  9. ;                ¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯ ¯¯¯¯¯¯¯
  10. ;                        converted
  11. ;                           by:
  12. ;
  13. ;                        » Lance «
  14. ;
  15. ;
  16. ;
  17. ;                ( TRASH - mode enabled! )
  18. ;
  19. ;
  20. ;----------------------------------------------------------
  21. ; Version 3.T
  22. ; In this new version of my PT2.2 replay routine there have
  23. ; been an major change. I have added TRASH - mode to the
  24. ; play routine. Believe me TRASH - mode is no trash at all
  25. ; (get it :-) ) and is ideal for my replay routine. TRASH -
  26. ; mode means that my replay routine creates buffers so that
  27. ; it don't harm if the replay routine and your nice 2,000
  28. ; pixels 3D ball sometimes together takes more time than
  29. ; the total rastertime ,just don't let happen to often.
  30. ; This ideal for my replay since it optimises the time it
  31. ; takes depending how many voices is active at the moment
  32. ; and how high frequency they are playing at the moment.
  33. ; For example if your nice ball is rotating on the screen
  34. ; and there sudden is a drum hit which make my replay
  35. ; routine demand more rastertime than there is available at
  36. ; the moment this replay won't sound crap or and your ball
  37. ; will not start to rotate jerky instead the routine will
  38. ; start eating of it's buffers instead. But there is only
  39. ; 8 buffers and just 8 vbl of precalcuated sound data isn't
  40. ; to small . I don't think so (please contact me if feel
  41. ; diffrent) since the replay routine is still updating the
  42. ; buffers just not fast enough. Let's say when the drumhit
  43. ; comes all buffers are filled up. Because of the drumhit
  44. ; the replay routine just 90% of time it needs. Still it
  45. ; can play for c:a 65 frames without sound distorsion
  46. ; (theoretical 69 frames) usually drumhit are shorter than
  47. ; a second. If the rastertime is exceeded for a long time
  48. ; then sound will sound real strange.If there was 16
  49. ; buffers then sound in our example will last c:a 3 sec.
  50. ; (theoretical :) the reality can be far more complex
  51. ; than my simple musicians).
  52. ; ADD : I have made a little change in the code since I
  53. ;       wrote this . I have added a constant called 
  54. ;       mt_frame_number which can be found directly
  55. ;       under my starting comments in the code.
  56. ;       It is set to 3 in the beginning which means that
  57. ;       there 8 buffers. If you change it to four you will
  58. ;       16 buffers and 5 == 32 buffers and so on so now
  59. ;       you decide for your own. The lowest you can set
  60. ;       is 1 don't try 0 and negative numbers It won't
  61. ;       work I can tell you.
  62. ;----------------------------------------------------------
  63. ; This replay is made to fit demos and democoder it's 
  64. ; purpose isn't to give the ultimate soundquality but to
  65. ; give near-top quality sound and to take as little time
  66. ; as possible. To do this I had to implent some tricks that
  67. ; not always will please the nice-to-the-system guy.
  68. ; The drawback for this code is that it sucks silicon 
  69. ; it eats memory in other words , but if you have one meg
  70. ; it should be enough (I hope) the replay also has one more
  71. ; major drawback ,some samples may sound very strange in
  72. ; this replay. It sounds that way since I have an odd way
  73. ; to calcuate the frequency which also make this replay as
  74. ; fast as it is (fast 50kHz routines usually cheats in one
  75. ; way or another).Usually the replay sounds good.
  76. ; To make more ideal for demos I have implented a function
  77. ; that the demo-coder calls to see which position the replay
  78. ; is at . Why isn't that just to read off the variables
  79. ; mt_songpos and mt_patternpos?
  80. ; Since it's a TRASH player it's not that easy.
  81. ; I will give the demo-coder to reason to time the demo with
  82. ; the music :
  83. ; 1: Demos with timing are nicer to watch and gives a more
  84. ;    proffesional impression.
  85. ; 2: If the demo-coder got himself a good musician (lucky
  86. ;    bastard) and is planning a time-consuming bit in the
  87. ;    demo then he can ask musician to use only 2 voices
  88. ;    there and using low frequencies to make my replay use
  89. ;    little time. If he is a good musician he can make it
  90. ;    sound good anyway. Then when the coder makes the demo
  91. ;    he just time it so that time-consuming bit comes at
  92. ;    the same time as the special music bit.
  93. ;    It's not hard but it's boring (XiA have made some real
  94. ;    cool 2 channels modules.
  95. ;---------------------------------------------------------
  96. ; How will I have to code to most efficiently use this
  97. ; superior TRASH - technique?
  98. ; As all good coders know there don't exist a 'best' way
  99. ; to do it but and idea is: First in your vbl rout you
  100. ; jump to mt_vbl then call your 2,000 pixel ball.
  101. ; In your main_loop outside the vbl you call the mt_update
  102. ; leaving it the time that is left of the vbl. And after
  103. ; the mt_update you call other TRASH routs with lower
  104. ; priority like depacking the next part.
  105. ;---------------------------------------------------------
  106. ; I realised that if you would like to do two frame
  107. ; things the trash mode is not ideal so I put in an 
  108. ; option to turn it off mt_trash_off and mt_trash_on to
  109. ; turn it on again.
  110. ;---------------------------------------------------------
  111. ; The part mt_music isn't my own code but ripped from 
  112. ; Amiga it is therefor not optimized , before when my 
  113. ; routines took 60%++ I thought that there was no idea but
  114. ; now I found it very irritating that it is so lame coded
  115. ; sometimes adds upto 9 rasterlines !! to my code,that is
  116. ; 10% of what my Paula emulator takes.
  117. ; If someone could offer me a good optimised PT2++ replay
  118. ; routine for the Amiga I would be very happy.
  119. ;----------------------------------------------------------
  120. ; And now a short explaination of the diffrent subroutines
  121. ; in pt_src50.s ...
  122. ; All routines shall be called with an jsr or bsr.
  123. ; mt_init         : Must be called initalises module,creates
  124. ;                   frequency codes etc. etc.
  125. ; mt_vbl          : The one you shall call first in your vbl
  126. ;                   rout or TimerA rout don't take much time
  127. ;                   unless you haven't turned trash off then
  128. ;                   it update next buffer
  129. ; mt_trash_on     : Turn on trash mode (trash mode is
  130. ;                   default).Just call it and let's TRASH :)
  131. ; mt_trash_off    : Turn trash mode off and forces update
  132. ;                   on the mt_vbl instead. Be little careful
  133. ;                   when you call these sub-routs ,don't
  134. ;                   call them from a interrupt
  135. ; mt_ask_buf_full : If all buffers are filled up then this
  136. ;                   sub-routs sets d0 = -1 else d0 = 0.
  137. ; mt_ask_position : Gives the song position in d0 and the
  138. ;                   pattern position in d1.
  139. ; mt_update       : If we are in trash mode this one update
  140. ;                   the buffers. Should NOT be called from
  141. ;                   vbl or any other interrupt. But in the
  142. ;                   main loop.Should also be given a high 
  143. ;                   priority.
  144. ; mt_end          : Call this when you are finished , don't
  145. ;                   do much but is necessary.
  146. ;----------------------------------------------------------
  147. ; Last : Please excuse my bad english ... The only language
  148. ;        I master is Machine Language(MC68000) :-)
  149. ;----------------------------------------------------------
  150. ; By the way : Have a wonderful life !!
  151. ;----------------------------------------------------------
  152. ;      - Lance / Mårten Rånge      1994/01/01
  153. ;----------------------------------------------------------
  154. ; P.S. This whole work was written in DevPac 3.00 
  155. ;      God Bless HiSoft                                 D.S
  156. ;----------------------------------------------------------